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END-TO-END BUSINESS PROCESS SOLUTION CREATION 

CROSS REFERENCE TO RELATED APPUCATIONS 
[0001] This application relates to and wholly incorporates the subject matter of commonly 

owned co-pending U.S. Patent Application No. (U.S. Attorney 

Docket No. YOR920030143US1 (16596)), filed June 5, 2003, the whole contents and 
disclosure of which is incorporated by reference as if fiilly set forth herein. 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0002] The present invention relates to business systems and infiastructures generally, and 
more particularly, to a system and method for creating and managing business process 
integration solutions. 

Description of the Prior Art 

[0003] Starting fix)m a business process fiom user knowledge and existing documentation 
and creating an optimized IT solution that operates and manages the process is presentiy a 
very expensive, time-consuming undertaking. Currently, business process modeling has 
limited usefulness, i.e., it is largely documented in text documents including freehand 
diagrams etc. and lacks formal semantics. Results thus comprise unstructured solution 
knowledge sharable only at the code level. Fiuthermore, completed solution caimot be easily 
or automatically reconciled with the original process model and business process performance 
is difficult to measure and use to reengineer the process. 

[0004] Known solutions to this problem currentiy are not cost-efticient nor time-efficient 
and, moreover, do not span tiie entire end-to- end business process. For example, Holosofic is 
a popular tool for creating business process models and workflows, but cannot be used to 
generate other necessary components, such as application adapters or business objects. 
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Crossworlds Interchange Server is a tool for implementing business objects and business 
logic operations, but does not perform business process modeling or workflow generation and 
processing. 

[0005] It would thus be highly desirable to provide a system and method for business process 
integration and management solutions. 

[0006] Furthermore, it would be highly desirable to provide a business level modeling 
language tiiat formally describes functional business models fiiom a variety of perspectives 
including a strategic operational and execution point of view tiiat serves as a basis for 
implementation as an Information Technology (TT) execution model, and further, facilitates 
business process re-engineering according to changing business goals and objectives over its 
development lifetime. 

Summary of the Invention 
[0007] It is an object of the present invention to provide a cost-saving and time-saving 
solution for providing a business process integration and management solutions, particularly 
novel procedures from which an IT solution for a business process may be created. 

[0008] According to the preferred embodiment of the invention, there is provided a complete 
system and methodology for creating business integration and management solutions. A 
point of novelty of tiie invention is its formal definition of the modeled business activities and 
output of each step in the solution creation process. In each step, one or more documents or 
other artifacts are created in accordance with well-defined schemas and specifications. Key 
steps are automated by algorithms in software, or assisted by tooling with graphical user 
interfaces. The schemas and specifications enforced the validity of the work products and 
guarantee compatibility with other components and the overall model. Another critical 
element is the incoxporation of key performance indicators in the veiy early stages, followed 
through with implementation of software probes to collect the business process performance 
data. Once the solution is deployed, these data are rq)orted to the business analyst for 
performance tuning and business process re-engineering. 
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[0009] In the achievement of these objects, a comprehensive methodology and tool set is 
provided for the complete lifecycle of a business process solution spanning: 
1) business strategy modeling at the strategy level; 2) business process modeling at the 
operational level and, defining in the operational model, the business process measurements 
in terms of conmiitments and key performance indicators; 3) and transforming of the process 
model to an information technology (IT) solution composed of solution artifacts of pre- 
defined types including: Business Objects, Adaptive Business Objects, Macroflows, 
Microflows, EAI Adapters, B2B Connectors, User Interaction Screenflows; 4) simulation of 
the models to perform static and dynamic analysis; S) mapping of the key performance 
indicators to IT probes in the IT solution; 6) defining details of the IT solution artifacts in an 
integrated set of graphical tools; 7) binding and deploying the solution artifacts to platform- 
specific runtimes; 8) Monitoring and reporting business process performance as measured by 
the key performance indicators being serviced by event data fi'om probes; and 9) optional 
invocation of agents to recommend and/or effect changes to the business process that improve 
its performance. 

Brief Description of the Drawings 

[0010] The objects, features and advantages of the present invention will become apparent to 
one skilled in the art, in view of the following detailed description taken in combination with 
the attached drawings, in which: 

[0011] Figure 1 depicts a generic block diagram illustrating the model-driven approach for 
bringing about Adaptive Business Solutions according to the present invention; 

[0012] Figure 2 illustrates the end-to-end Business Process Modeling system and components 
100 according to the present invention; 

[0013] Figure 3 illustrates conceptually the business solution creation life-cycle according to 
the present invention; and. 
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[0014] Figure 4 illustrates conceptually the Business Operational Specification (BopS) model 
for representing an operational view of a business. 

Detailed Description of the Preferred Embodiments 

[0015] This invention defines a procedure by which an IT solution for a business process can 
be created. In each step a specific set of artifacts are created for possible use in future steps, 
or for later re-use during creation of additional solutions. 

[0016] Figure 1 depicts the model-driven approach 10 for bringing about Ad£q>tive Business 
Solutions. In this approach, the business semantics are captured and then IT changes are 
directly impl^ented that change the biisiness. The approach includes: (1) a step of modeling 
businesses at the appropriate levels of abstraction for each main user role and purpose, and 
(2) mapping, transforming, and coxmecting these models to one another and to the IT 
infiastructure such that manipulating models corresponds to manipulating implementation 
code. The benefit of manipulating models rather than code is that generally, models are easier 
to imderstand and manipulate than code. For example, a bxisiness xiser - whether this is a line 
of business manager, business analyst or a business process designer specialist - who needs to 
modify a business operation does not want to manipulate Java code or even BPEL (Business 
Process Execution Language) scripts to understand the current process or make changes to it, 
just like an object-oriented Java developer does not want to manipulate assembly code. 
Rather, the line of business manager wants to manipulate a visual business operation model, 
which is the appropriate level of abstraction of this business semantic for this user and 
purpose. 

[0017] As shown in Figure 1, the approach 10 includes a step of malcing the models become 
executable like code. Three levels of models for three main user roles and organization 
pxirposes includes: 1) a strategy model 12 that defines tiie business goals and objectives, e.g., 
in the form of scorecards (quantification of goals) and targets (measurable objectives). Such 
strategy modeling is performed, for instance, by an executive 21, or like business 
professional; 2) the operation model 14 defines what the business does in terms of business 
processes, commitments, and KPI (Key Performance Indicator) metrics which get mapped to 
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the scorecard for comparison with their strategic targets. Such operation modeling is 
performed, for instance, by an Line-of-Business (LOB) manager 3 1 , business analyst, or like 
business level user. In the generation of the strategy model, data link structures are provided 
to map the strategy model with the operations model. Preferably, the operation model 14 is 
semi-automatically transformed into 3) an execution model 16 that defines how the business 
operation is executed in terms of specific applications, data sources, people and partners - but 
in a platform-independent way. Such execution modeling is performed, for instance, by an IT 
architect 41, or like IT professional. In the generation of the strategy model, software data 
structures are provided to transform the operations model into flie execution model. Finally, 
some development may be required to connect the platform-independent execution artifacts to 
4) a specific platform implementation model 18 such as the WAS J2EE or MS .NET 
platform, and implement specific APIs such as by using Web Services, for example. Such 
implementation modeling is performed, for instance, by an IT developer 5 1 , or like IT 
professional. 

[0018] With these mappings, transformations, and connections in place, raw events, 
transactions 23, and environmental data can be captured and aggregated into business metrics, 
e.g., return on investment (ROI) or Earnings per share (EPS), for comparison with business 
commitments and objectives in a Business Activity Monitoring (BAM) dashboard, for 
example. Through a number of feedback loops 25a-25c, Continual Optimization / Sense and 
Respond (CO/SaR) technologies may then provide decision support to manage operational 
exceptions and proactively suggest process changes to optimally achieve business objectives. 
Finally, changes in business direction can now be directly propagated fix)m the strategy model 
down to the IT infi:astructure mostly by manipulatmg models rather than code - requiring far 
less time and cost than traditional business transformation engagements. This allows the 
business to adapt as quickly and easily as adapting the models. 

[0019] Figure 2 illustrates the end-to-end Business Process ModeUng system 100 and 
components. In a preferred embodiment, the first step 103 of the ABS concept is to populate 
a Business Level Modeling (BLM) repositoiy, e.g., a memory storage device or database 1 10, 
usmg externally defined business content. The above-described business professional, e.g., 
executive, may implement a business strategy modeler tool or any like method of gathering or 
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generating externally defined business content for storage in the repository 1 10. This content 
includes, but is not limited to, documentation of the business process that may aheady exist or 
may need to be created tibrough interviews wifli people involved in the process. Next, at step 
106, involves utilizing a business analyst (e.g. business operations manager) to create a 
formal model of the business operation, e.g., by using a tool called the Business View Editor 
(BVE). The BVE is a graphical tool that allows a business user or analyst to create a model 
of the business process as a diagram 200, of which each component and connection has a 
well-defined meaning. The graphical representation 200 of the process has a corresponding 
textual representation in a document conforming to a schema, such as an XML schema, for 
example. As will be explained in greater detail herein, such schema provide a formal process 
sub-model of the business operations including modeling process tasks, business artifact 
flows and artifact i^sitories. The business process model 200 may be stored in the same 
Business Level Model (BLM) repository 1 10, for later retrieval, re-use, customization, or 
modification, or in another like repository (not shown). As will be explained in greater detail 
herein, the business process model is described in a formal language referred to as BOpS 
(Business Operational Specification) that specifies the operational view of a business. 
Another step 108 implementing a tool, called a Transformation Wizard 150 is used to 
transform a BLM 200 into an IT Level Model (ILM) 250. Such a transfoimation process is 
described in further detail in commonly owned, co-pending U.S. Patent Application No. 

- (U.S. Attomey Docket No. YOR920030143US1 (16596)) 

incorporated by reference herein. 

[0020] More specifically, the Transformation wizard 150 may automatically transform the 
business level model to an IT level model (ILM) 250. The Transfoimation Wizard may be 
automated by one or more alternative algorithms that use different approaches to generating 
an rr architecture for the solution. The algorithms identify the necessary components that 
will be used in the ELM 250 including, but not Umited to components, such as: business 
objects 201, adaptive entities (adaptive business objects) 202, screenflows 203, macroflows 
and workflows 204, microflows (automatically executable tasks) 205, and application or 
business-to-business adapters 206. An adaptive entity is a prescription for tiie various states 
that a business object can have an d transitions that a business object can undergo. A 
woricflow is a sequence of activities, some of which involve human interaction. An 
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^plication adapter is software that allows an independent application to be integrated with 
the process. A business-to-business adapter is software that ^lables an external business 
partner to be integrated with the process. 

[0021] Further steps 115 are performed by the IT developers 51 who implement runtime 
development tools 185 such as IT Level Editor or "Binding Wizard" tool (not shown) that 
may be used for viewing or modifying the artifects at this level. Typically, one or more IT 
Level Artifect Editors are employed to further specify the details of each component. This is 
necessary because it is not realistic for the business level model to contain suflBcient detail to 
fully define all components at the IT level. Separately, adapters for the existing applications 
and business partners are either retrieved (if they had been created previously) or created. 
They are retrieved from the Asset Repository 400, and used by a "Binding Wizard'' tool, 
along with the artifacts in the ELM to generate the bindings between components, which are 
then stored in the asset repository 400. The binding wizard particularly uses the adapter 
defined and the commands in the ILM repository to create concrete bindings. 

[0022] A further runtime development tool is a Package Generator creates a deployable 
solution, e.g., files, and deploys them on local or remote machines. That is, based on the 
selected software and hardware platforms and topology, platform-specific components are 
created and the entire solution is packaged and stored in a runtime arti&cts repository 500. 
This package is then ready for testing and deployment in a customer's environment. 

[0023] Figure 3 depicts conceptually, how the business solution is created and managed over 
the development life-cycle 275. As shown, the business objective of finding an intended 
solution includes a hierarchy of formally representing the bxxsiness operation model 280, e.g., 
using a business process modeling language such as BOpS as will be explained in greater 
detail herein; performing static and dynamic analysis 282 on a related "runtime" platform 
such as a simulation engine 283. As described herein, to build the intended solution requires 
developing an architectural model 285, developing IT artifacts 287 and then generating 
integration middleware (WBI) 289. From this, the business is observed and monitored by 
performing steps of generation of the business observation model 290, customizing the 
business activity monitors 292 and implementing probes (to feed model) and dashboards to 
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view model 295. The observations and monitor data are feedback 297 to the first hierarchy in 
order to further refine and find the optimal solution. 

[0024] As described hereinabove the Business Process Model is described according to a 
Business Operational Specification (BOpS) which is a business level modeling language. 
Bxxsiness level models provide a formal representation of a businesses operations, reflecting 
procedures and business policies, customer requirements, constraints, and a solution context. 
Business Analysts and Line of Business users will define such models. 

[0025] Business level models can be used stand-alone, independent of any IT 
implemotitation: for cost anal;^is, process simulation, resource allocation or optimization 
studies. One of the intended purposes of a BOpS model is to serve as the basis for this class 
of stand-alone appUcations. In addition, a BOpS model is intended to be used as a starting 
point, and top-level *1)rackef ' for IT implementations: as a starting point, becaiise additional 
tools and procedxires will be provided that will help refine the model to the level of 
executable solutions; and, as a top-level bracket, because the BOpS model will remain 
interlocked with the deployed solution, and serve as the basis for business activity 
monitoring, process analysis based on real-time data, and process re-engineering. 

[0026] Other extensions of a BOpS model may cover enterprise models for resource 
allocation and deployment, accounting and chai^ging, asset management, security, directories 
and organizational structure, mterprise information models, internal and external 
communication channels, etc. It is expected that a BOpS model serve as a common core and 
starting point for virtually every aspect of modeling an enterprise. 

[0027] A BOpS model is a formal representation of the business owner's view. A second 
way of positioning BOpS is with respect to the solution development Ufe cycle: It is the first 
formal representation of a solution, succeeding the initial opportunity assessment and 
requirements gathering, strategy formulation and preceding any IT architecture definition. 

[0028] Yet another way of positioning BOpS is with respect to the granularity of modeling a 
solution: It is the most fine-grained representation that business-level users will recognize. 
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From a business user's point of view, BOpS tasks, resources, and artifacts are "atomic". (One 
may tear an invoice in pieces, or disassemble a computer, but the results will no longer be 
recognized as '^business documents" or "system resources"). 

[00291 There are diree views of a business system. The operational view that projects what 
the business does, the strategy view that describes why it does that, and the execution view 
that depicts how it does fliat. Most of the work on business process modeling focuses on the 
execution layer. BOpS is built on the idea that the best way to present the operational view of 
a business is to focus on the artifacts fliat die business operates on and the business elanents 
that impact the lifecycle of those artifects. These business elements M into three categories: 
business tasks that represent irreducible business functions performed in the context of those 
artifects, artifect repositories that serve as die storage for these artifects, and the business 
processes that define a topology on an aggregation of business elements. The business model 
described by BOpS is further decomposed into Haee sub models. The information model 
captures the business artifects and business events. The functional model captures business 
processes, business tasks, and die artifact repositories. The resource model captures the roles 
and resource groups. 

[0030] It is very natural to find that modeling busmess operations involves modeling these 
three fundamental constituents of a statement: Subjects (actors), veibs (actions), and objects 
(artifects). Coirespondingly, as shown in Figure 4, a BOpS model 300 has fliree parts: a 
Resource Model (describing die actors) 302; a Functional Model (describing die actions) 304; 
and, an Information Model (describing die artifects) 306. The Resource Model 302 describes 
die actors and dieir capabilities. Resources 308, which may be human, automated, or 
extanal, qualify for roles, which are defined as aggregations of c^abiUties to perform tasks. 
Roles 309 may be "scoped", in which case diese capabilities have task instance (or artifact) 
dependencies. It is noted that resources may be owned by organizations (business units, 
departments, partners. . .). The Functional Model 304 describes die actions in die fonn of 
business processes, business tasks and artifact repositories dmt serve as die storage of die 
artifacts diat die business operates on. It is also where die coherence of die model is 
established: Which tasks operate upon which artifects using what kind of resources, and how 
tasks are interconnected (sequenced) tiirough die exchange of artifects. Finally, die 
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Information Model 306 describes the artifacts ("documents'*, *Vork products") 312 and 
business events ("messages", "signals") 314 that business tasks exchange. In addition, it 
features task contexts, which hold temporaiy information needed by a task, and business 
predicates, which model constraints for, and relationships between, all information model 
constituents. 

[0031] As further shown in Figure 4, there is illustrated the use of two complementary 
models that woik in conjunction witii BOpS. The Business Process Commitment Language 
(BPCL) 316 is used to specify the Key Performance Indicators (KPIs) 318 of the business 
operation. The Simulation Model 320 including schema 322 to specify the simulation 
parameters of the business operation. 

[0032] An overview of the syntax of BopS is now described with details of each language 
construct described in greater detail herein. At the highest level, BOpS xxses the Business 
Model construct to define the operational view of a business. Included in the business model 
are the Information Model, Functional Model, and the Resource Model. This specification 
uses an mformal syntax to describe the XML grammar of the XML Augments below: The 
syntax appears as an XML instance, but the values indicate the data types instead of values; 
Granunar in bold has not been introduced earlier, or is of particular interest in an example; 
the <~ description ~> is a placeholder for elements fit)m some "other" namespace (like 
##other in XSD); characters are appended to elements, attributes, and <!- descriptions -> as 
follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more). The charactere "[" and "]" are used to 
indicate that contained items are to be treated as a group with respect to the "?", or "+" 
characters; elements and attributes separated by "1" and grouped by "(" and ")" are meant to be 
syntactic alternatives; the XML namespace prefixes (defined below) are used to indicate the 
namespace of the element being defined; examples starting with <?xml contain enough 
information to conform to this specification; others examples are Augments and require 
additional information to be specified in order to conform; XSD schema is provided as a 
formal definition of grammar. The syntactic structure of the root businessModel is now 
described with the basic structure of the language as follows: 

<buS^4od^^ ~^ ■ 

Miunlas='*'httD:/A^ ' J ^ 
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, , <inforrhatiotiModeI> 7~ 
' . ' , ,^ fnformatiohmo^el 
;<yii)fennationMo3cl>^ ' 



</bus!nessProcess> gf ^ ^ ^ ^ ' " 

- ^ . ^ tnisinesselemehttbusinessTask)' ' \ ' : ' f 



imsiiie^elm^t (businessTask)^^ 
</businessTask>fv ' '^^ 




[0033] According to the basic stracture shown, the top-level attributes are as follows: "name" 
which attribute defines the name of the model; "taigetNamespace" which attribute defines the 
targetNamespace of die document; "expressionLanguage" which attribute specifies the 
expression language used in the process. A current default for this attribute is XPath 1 .0, 
represented by the URI of the XPath 1.0 specification, e.g., at 

http://www.w3.orgA'R/1999/RFr-^p «th.iQOQi i the "informationModer describes the 
above-mentioned artifects and business events pertaining to the operational view of the 
business; the yuctiomlModer describes Ae above-mentioned process, task, artifect 
repositories and their interconnections using ports and links; the "resource Moder describes 
the above-mentioned organizational roles and the resource groups relevant to the business 
operations; and die "constraint^' describes the constraints that ensure the semantic vaUdity of 
a BOpS business model. 
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FUNCTIONAL MODEL 



[0034] As mentioned, the token ''businesselemenf can be any of the following: 
businessProcess; businessTask; and artifactRepositoiy. The <busmessPn)cess> construct 
describes the business process with the basic structure of the language as follows: 



< businessProcess name==^'n<»ame'^ abstract*" truc|fa!se"? extcmal=^" tnic|feise"? '~~7- 

^ automatic=^" true|felsc'7 transaction^^" true|false"? compensation^^ tme|felsc"?> 

. <linla>? ; " . / 

<inkfromport7'iicnanie"toport=^*ncname"/>* : ' 

, Imsinesselemeni (businessPr(K€^^ 
roles? . _ y J*' / 

<^buSlltey$ProO^ .-;y;^--;. 



[0035] The <businessTask> construct describes the business task as follows: 



<busin^Task nameT''n<mame" iitomatic«"tn5f^^ ] 
4Compensatiptt7"true|falsel'?>" \ 

^ . ^ <contextyanablenatneF=*!n(3iamc"ty^ 

' " ■ . ^ t <px«dicate namc?*"ncttame" expression*^^^ 

; <trigger timer^ W]feI^e*7 sel^tmep^ . \ 

• • ^ - . <portid=^'ricaiame">f "i; '-'-V \" <.;^^* \ . - . < 



[0036] The <artifactRepositoiy> construct describes tiie artifiict lepositoiy as follows: 



<aitifactRqiositoiy nanae^cname" labclf"sttmg?7> , ; T T 

C ' -sports? V f ^ 1, ' \ v^;^""'', ; -i^ . *!._,|;^ 



[0037] The token ''ports'' referred to above is described s follows: 



<Jx)rts> 

<Jx)rt name="string" diiection'==" injout|in-butlout-itf ' predicate^"string'r? identifyPasse^" tmelfalse"^ 
pioxyOf="ncname"?>* ^ ' ~ , ^ * 

choice 



<businessArti&cCrypeiiam6=fncnme"/:> 
\ -^^r <)usinessEvCTitTypenanie*rncname''>.-^ 

'-^ choiw., .r ' ? 

. .4 , ^ <i>redicate,nameF^ncnWe" expression="string*'/>? 
/ <yporf> , 
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INFORMATION MODEL 

[0038] The token 'Hnformationmoder referred to above is described as follows: 



<busincssAitifactTypcnameF='*nciijame'*^^^^^ 
<5)usinessEyentType name=^'nciimc'' tYpe='7qi^^ 



RESOURCE MODEL 

[0039] The token ''roles'' referred to above is described as follows: 



<*olcs> \". 

<role rolere^"qname^* ; ' I : 
^ %4M^:role>? 

<bnn:rolc> ' 

</TDlesi> ^ 



[0040] The token ''resourceGroup'' referred to above is described as follows: 



<resource nameF=j^s6ing" aggfegadpnTyp^^n)ag|sequWcc|alt€mativer'>* -- 
<hvmanResource namef^s 

\, tAu>micRespurce „ ^ ' < - 1 ^ ''*'^* V 

> <lxumanJfesource name^**string'* aggrcgationTyper'T)ag|sequen'ce|altemative?" 
humanRcsoi^ .^y ^ , / ^ f 

<sys6ji0^esome aggi^tionType«*T)ag|s©quence|dternativcr'>* * ^ 

tAtomicResource . ; . ^ < , ; « h.^' 

5 sj^temResource name=="string" aggregationType='^ag|^uencc|altemative?'V^^^ 
</ systanResbiu:ce>' /- - . - -j^: •;• j • 'i|'>''.; - ' — ^ - " ' ■ - " - 
<fexterMlR«ource namef^string" aggregati'onTypc^^agj^equence|dte™^ 



[0041] The token ''tAtomicResource'" referred to above is described as follows: 



<attributcs>? 

- ' <attribute namcp=**string*' value="string''?>h . , 
<dcscription/>* , , , 
</a5ttributtf> . . , / 

<attributefi>*. \ "'^^i^^^ " \ ' 

i<rolcname==^'strfeg^'>4: "f^^^^ "^ ^.i- , f' ^ 
"ii '<scopenaine=^t'stririgf'?^ue^^ 

</n>ies> Y ■ --"^^ - •'• V / " j 
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CONSTRAINTS 



[0042] The constraints are described using Boolean Xpath expressions and must evaluate to 
true for the model to be semantically valid. The token '^Constraints'' referred to above is 
described as follows: 



<constraints>? 

<^nstFamt nameF='^ncname'' expressioiP="string">* 

<description/>? ■ • 

</constrainP' . - . 
<Vcoiistraints> ^_ \ . 

[0043] BOpS business models capture the lifecycle of the key artifacts of the business 
operation and tiie business events that impact the lifecycle. Business logic at the operational 
level is captured using business predicates. Business artifacts, business events, and the 
business predicates are the imderpinnings of the BOpS information model. 

<xs:jcoiiapIexT5TS nam,e="tArtifect"> / ^\ ^ - ' ^~ ' I 

<xs:attributeiiame=="name" ^e="xs:N(^ 

<xs:attnbutenameT="t53)c"l5^p - . ... \ 

[0044] BOpS business models capture the lifecycle of the key artifacts of the business 
operation and the business events that impact the lifecycle. Business logic at the operational 
level is captured using business predicates. Business artifacts, business events, and the 
business predicates are the undeipirmings of the BOpS information model. 

BUSINESS ARTIFACTS 

[0045] The use of BOpS in defining the operational view of fliis example business and a 
description of the businesss' core constructs is also provided. In an example travel agent 
business, a travel reservation process identifies the required flight legs and hotel reservations 
for a customer* plaimed trip. It then spawns sub-processes responsible for reserving the 
flights and hotels. If all reservations are confirmed within a pre-defined time limit, an 
itinerary is printed and sent to the customer. 

[0046] As mentioned, the BOpS captures the lifecycle of a business artifact as a flow of an 
artifact type through the business elements. The cardinality attribute of the artifect type 
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indicates any limits on the instances of a certain artifect type. The artifact type also identifies 
the infonnation variables for that artifact type. An artifact is either worked on by a Business 
Task or resides in an Artifact Repository. An artifact has the following attributes: name : 
ncname - specifies the name of the artifact; and, type : qname - specifies the type of the 
artifact. It is a qualified name so it could be in another namespace. An artifact is described 
by its type attribute that is a qualified name (referring to a namespace). The syntactic 
structure of an example artifact is as follows: 

<;jcs:cojnpl€xTxpeiiame=="tAjtifecf'> . ^ - . ^- Jf ' 

« <xs:attributeiianie«"iiame" typep="xs:^ ^ , ^ , , 
<xs:attri!wte name=7"type" type="xs:QNam . 
</xs:complexType> : - " — 

BUSINESS EVENTS 

[0047] Business events (for example, a fax or a phone call fix>m a customer) may carry 
artifact references or copies of artifact content. Thus, a business event has the following 
attributes: name e.g., "ncname*' specifying the name of the artifect; and, type, e.g., "qname" 
specifying the type of the artifact It is a qualified name so it could be in another namespace. 
A business event is described by its type attribute that is a qualified name (referring to a 
namespace). The syntactic structure of a business event is as follows: 





«iessEvent">^. - < : 1 : 






<xs:cpmpi^xXype 4iaihe^"tBusi 








/ <xs:complexCoht«it: 




illliill 





















BUSINESS PREDICATES 

[0048] A business predicate is an expression of conditional logic in terms of the information 
variables and/or artifact attributes in the model. A business predicate can be used in the 
following sections in the BOpS model: a Port - as a boolean expression whose evaluation 
decides if the artifact flows througih flie port; a ContextVariable - as a regular expression 
whose evaluation sets the value on the variable; and ConstFaint(s) - as a boolean expression 
whose evaluation validates the model. A predicate is expressed using XPatii. It has the 
following attributes: name : ncname - a unique name for the predicate; and, expression : 
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string: an XPath expression expressed in terms of an artifact, business event or context 
variable. The syntactic structure of a predicate is as follows: 



<^s:complexT)Tpenarne=T"tPrcdicate"> - . 




<xs:at|Tibute iiameF=rname:;txpe==="xs:NGN£m us©^"required") 




^ <xs:attribute name?''expi^b^^^ 
</xs:coniplcskIVb^> -^"^^^^^ ^-:-*- - -^"^ t\^> f - 



[0049] As mentioned, the Business Function Model includes BusinessElements and their 
connections. A Business Element is a general construct in the functional model, i.e., it is 
manifested as a Business Process, Business Task or as an Arti&ct Repository. The Business 
Function Model is built on the core concept of business artifacts (e.g. purchase orders, 
customer records, contracts, invoices). It is noted that the structure of business artifacts and 
business events is described using the constructs of die Information Model, while their life 
cycle is described by the Operations Model; and business events (e.g. timer signals, alerts, 
notifications) being exchanged amongst business tasks. Business tasks have ports through 
which artifacts and events enter or exit. The ports are connected via links. Furthermore, the 
model features artifact repositories, which is where business artifacts reside when they are 
not processed in a task, and business processes which aggregate tasks, artifact repositories, 
and potentially nested processes, into larger operational units. It is noted that a fundamental 
difference between the Business Function Model and many of the existing "flow models" is 
fliat in BOpS, there are no flows. There are only tasks^ which are spawned by an arriving 
artifect or event, perform some work, and finally send out events and arti&cts which may 
spawn other tasks in turn. This creates a "web of interacting tasks" connected through the 
exchange of arti&cts and events. One could follow the path of a particular artifact and define 
the sequence of tasks thus encountered as a "process" or "flow". However, with this approach 
a given BOpS model may be dissected into flows in many ways, and for tasks operating on 
multiple artifacts, it may not even be clear to which flow or process they belong. While a 
"business process" construct in BOpS is available, this should really be thought of as a 
"composite task", since fi-om the outside, it looks and behaves exactly like a task, with ports 
to send or receive artifacts and events. The only difference is that for processes, their internal, 
operational structures are further decomposed within BOpS, while elementary tasks are not. 
The roles are defined in the Resource Model and referred to fix>m the BusinessModel. A role 
identifies who can perform a business function. 
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BUSINESS ELEMENT 



[0050] A biisiness element is an abstract construct BusinessProcess, BusinessTask and 
ArtifactRepository all extend BusinessElement The syntactic structure of a business element 
is as follows: 

<xs:compIexType name="tBusinessEI«ncnt"> . - ' , ^ ^ " 

<:xs:coinplcxCoritent> I?V V'';^^* \ ' ' 

* f <xs:elcmCTtnamef"dcscription" 
t * S/xs:sequence> ^ . ' , . 
<xs:ktribute'name«"name" type=^"xs:NG^Jamc*^ 
* — <;/xs:extension> ^ ^ 

/<;/xs:complexContent> $ , : / 
„ - <xs:complcaCIVpe> . ^ ' • - l-- > 

[0051] Ports define the interface of a business element. A port has the following attributes: 
a name : ncname - name of the port; 

a direction (in|out|in-out|out-in) - The direction of information flow in the port. 
Particularly, "in" indicates that a businessArtifact or businessEvent is received on this port. If 
the port is defined as a trigger port, it will trigger (see task trigger) the start of the task. It 
must be connected to a corresponding 'out' port via a link; "out" indicates that a 
businessArtifact or businessEvent is sent out via the port. An output port cannot be specified 
as a trigger (see task trigger) for the task. It must be connected to a corresponding *in' port 
via a link; "in-out" indicates that a request is received for a businessArti&ct and a 
corresponding response is sent back. An in-out port cannot be specified as a trigger (see task 
trigger) for the task. These ports are valid for all businessElements and normally specified 
within artifactRepositories. It must be coimected to a corresponding 'out-in' port via a link; 
and, "out-in" indicates that a request is sent out for a businessAtifact and a corresponding 
response is received. If the port is defined as a trigger port, it will trigger (see task trigger) the 
start of the task. The understanding here being that the task was listening/polling for certain 
artifiict(s) based on a predefined conditioiL These ports are valid for tasks and processes (not 
artifactRepositories). It must be connected to a corre^onding *in-out' port via a link; 

a predicate : string - a boolean XPath expression whose evaluation determines 
if the port is active. Information can flow only through an active port; 
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an identityPassed : is a boolean(true|false) value indicating if the identity of the 
artifact is passed as part of the infonnation flow. At any instance, only one (1) 
businessElement can hold the identity of an artifact. A businessElement releases 
artifactldentity via 'out' or 'in-out' ports whose 'identityPassed' attribute is set to 'true'. A 
businessElement receives artifactldentity via 'in' or 'out-in' ports whose 'identityPassed' 
attribute is set to 'true'. The default is set to true; and, 

a proxyOf : ncname indicates referral to a physical port. This attribute 
mdicates that this port is a proxy port and actually refers to another port It is only applicable 
for non-abstract processes (which must have ports referring to ports belonging to its child 
processes, tasks and repositories). 



[0052] The syntactic structure of a port is as follows: 



t , ; .^s:cpoice>s. ' . v. . . . . 

<xs:elem«it i^e="busirie^EyentType!^ typ^rbops:tBusmessEvcntRef' /> 
: <xs:eleme«thto^*1>usme&^ti^^ 

<xs:elemeiit nto^^predicate** t^pjeF^''bo^s:tPredicate" imnOc.curs^"0"^> 

^s:attnbul»iimn^"Bame" l>Tp^^^^ ^ . \ * _ 

<xs:attri^teWme«*^dii:^ ^ ' ^ ^ 

' 5^s:alti!8&^:tiame«"^ 
</xs:coTnplexType> 



</xs;seqiience> 



recucate;Hype=: xs:«Vi^ame use?7 opuo^ai /.^^^^^ . ,5 



i?xs:re^ctiph baseF5"xs:stnng?> . y , ^\ \ t J 



,.<xs:cnumerationya1ujeR^i9l*^ 
- :*<xs:«iumeratr(|ii va^^^ . ; 
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BUSINESS PROCESS 

[00531 A Business Process is an aggregation of business elements, i.e., business tasks, artifact 
repositories, and other business processes to support hierarchical structures. A process has 
the following attributes - 

name : ncname - specifies the name of the business process 
abstract : boolean (truejfalse) - A process with its abstract attribute set to 'true' 
is not hierarchically broken down into further tasks and artifect repositories and is treated as 
an opaque element. It contains only ports to define its interfaces and roles to denote who can 
perfonn its function. If the abstract attribute is not specified, the value defaults to 'false'. 

external : boolean (true|false) - A business process with the external attribute 
set to *true' indicates that it is external to the enterprise domain of the business that BOpS is 
modeling. The current version of BOpS models die operations of a business and the 
interactions of that business with its partners in the context of those operations. If the 
external attribute is not specified, it is assumed to be 'false'. An external process would 
necessarily be abstract (e.g. a manaufacturer would not define the business process of its 
suppliers) unless otherwise specified, 

automatic : boolean (truejfalse) - A business process with the automatic 
attribute set to 'false' indicates that the process requires human intervention to complete. All 
tasks within this process inherit the automatic attribute and can override it if necessary. .If the 
automatic attribute is not specified, it is assumed to be 'true'. 

transactional : boolean (true|fidse) - A business process widi its transaction 
attribute set to 'true' indicates that the entire process is treated as a long running transaction, 
i.e. if an exception occurs during flie execution of a process, the entire business state should 
be reset to the state prior to the commencement of flie process execution. If the transactional 
attribute is not specified, it is assumed to be 'false'. All tasks inherit the transactional 
attribute of its parent process. 

compensation : boolean (truejfalse) - A business process with its 
compensation attribute set to 'true' mdicates that it supports compensation in the event that it 
needs to be "rolled back". If the compensation attribute is not specified, it is assumed to be 
'false' . All tasks inherit the compensation attribute of its parent process. 
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[0054] The business model must contain at least one business process. The business process 
consists of business elements (process, task, artifectrepository), ports, links, and roles. Ports 
specify the interface of the bxisiness process. Roles specify who have the authority to perform 
the business function represented by the bxisiness process. Links connect ports of the 
business elements contained in the business process to specify the flow of artifacts through 
the business elements. A link has the following attributes: 

fromport : ncname - a reference to a port id. The direction of the port must be *out' or 
*out-in\ 

toport : ncname - a reference to a port id. The direction of the port must be 'in' or 'in- 

out\ 



[0055] The syntactic structure of a link is - 



<xs:a>mplexTypename=^"tLiiiks> 7 ! 




<xs:( 



[0056] The syntactic structure of a business process is: 



'/ - ^' / </xs:sequence>^ ' , ; >, ' " . - 

<xs:ai^bute,nanie=="^ 

I / <xs:attribute nab^ type=>s:boplean'^Jus^"^^^ 
< t ^; ^ t^^r" narae^tnmMCtion^^ usef^optioiwd" defaul|^"false"?> 

.. . ' . ' £ . - \. <ks:attribute.nam^ use=T"oDtional" defj£ilt="false"/> 

/ . ' </xs:extensioii>: 
• % </xs:coniplexConteati> 
<xs:cQinplCTTypfe^^^. • 



s:attribute,name=€(»if^eiisadonVt^^ use=T"optional" defj£iltj"false"/> 
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BUSINESS TASK 



[0057] A Business Task is an irreducible functional business element in the business model. 
Business Tasks work on artifacts. A task has the following attributes: 
name : ncname - specifies the name of the task. 

automatic : boolean (true|false) - A task with the automatic attribute set to 'false' 
indicates that the task requires human intervention to complete. All tasks inherit the 
automatic attribute of its parent process and can override it if necessary. . If the automatic 
attribute is not specified, it is assumed to be 'true'. 

transactional : boolean (true|felse) - A task with its transaction attribute set to *true' 
indicates that the task is transactional i.e. if an exception occurs during the processing of the 
task, the entire task is rolled back. If the transactional attribute is not specified, it is assumed 
to be *false\ All tasks inherit the transactional attribute of its parent process. 

compensation : boolean (true|false) - A task with its compensation attribute set to 
*tnie' indicates that it supports compensation in the event that an exception occurs. If the 
compensation attribute is not specified, it is assumed to be 'false'. All tasks inherit the 
compensation attribute of its parent process. 



[00581 A business task consists of ports, taskcontext, roles, and trigger. A business task 
should have at least one port, while Ae taskcontext, roles, and trigger are optional. The role 
is used to identify who has the autiiority to perform a business task. 



[0059] The syntactic structure of a business task is: 



. y r >- > > , '>jAf^^:^let^&^m f^e^ibopsitTrigger" miiiOccursF"0"> /i 

</xs:sequen<i>l ' • V ' 

;r ^ <xs:attributenaine=: auto 

, : - . <xs:attribute.aame="transactiobal";^ use*"optlonal" default="true"/i> 

t / 5; ■ ^ <xs:aCib»te^|iamer"coni^ use="optional" default="false"/> 
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TASK CONTEXT 

[0060] One or more "contextVariables" may be defined for a task. A task context defines 
task-specific information. Potential uses of such information is to: 

Define variables that can be used within Boolean expressions (expressed as 
predicates) in a port, whose evaluation decides whether a port is active. 

Assign a value to a scope variable. The resource assignment of a task depends on the 
correct assignment of the scope variable 

[0061] The syntactic structure of a taskcontext is: 

<xs:sequenc^ . -\ \ ^..,4^' ' . T*^- ' J i** ^ ■ * 

. <xs:elementiiame=?'TOnte^^ ' ^ 



</xs:c6roplexX yp e> , ^ f / J - ' / , ^ ' 'il^ : — i ^ 

TRIGGER 

[0062] Tasks are functional units that start processing when triggered and are guaranteed to 
stop after some reasonable time. A task is triggered according to the following: when an 
artifact enters via an 'in' port; when an artifact is available in a repository (in which case the 
call-back mechanism triggers the task via an 'cut-in' port); by a timer, or by itself 

[0063] The syntactic structure of a trigger is: 

<xs:doniplexT>pe name="tTrigger|>^ , " . ] ^ ^ 




<xs:sequenc6> 



<Xs:element narae=^port" TninOccurs="0" m&OccuTs="unbounde(i"> 




<xs:conq)lKcType>r 



<;/xs:coinplexTyp^ ^ 



. , , </xs:element>. - : 
</xsn5equence>'. ^ 
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<5cs:attribute name="timci^ t>peT"xs:boolean" us^"q 
<^s:coinplex?fti3e>';^^ ' - . - 

BUSINESS ARTIFACT REPOSITORY 

[0064] An Artifact repository is the "staging area" for business artifacts. An instance of an 
Artifact Repository can only hold artifacts of a particular type. Artifact repository is used to 
model temporal dependency with ordering constraints in the business model An artifact 
repository has the following attribute: name : ncname - that specifies the name of the artifitct 
repository. Ports define the interface of an arti&ctrepositoiy. Since an arti&ct rq)ositoiy can 
hold only one type of arti&ct, all the ports must reference the same artifact type. The valid 
port directions are: 'in', *out\ and *in-out\ 

[0065] The syntactic structure of an arti&ct repository is: 

<ks:cdtn^lexType nkneF^^tArtifactRepository"> fu : \ \y] ^ ' J. ^ ^ \ 
- ■ ; <^:coinplexCohteh . ' V_: *• '-''^C. ' Ic. ' ' 

' <bcs:extensionbas^"bpps:ffi ' t ' 

RESOURCE MODEL 

[0066] The Resource Model describes the actors performing business tasks, as well as their 
capabilities. A set of capabilities to perform business tasks defines a role. Actors are 
modeled as resources^ and resources qualify for a role, if they are capable of executing tiie 
corresponding tasks. They may then be assigned to these task for execution, if they are 
available, and not restrained by scope considerations (see below). Note that "performing" and 
"assisting" resources at this level of the model is not differentiated. The boundary between 
the two is blurred, and usually resources participating in task execution will be occupied, 
consumed, or charged for, regardless of whether they are "performing" or "assisting". Even if 
a resource is capable of performing a business function (i.e., it qualifies for the corresponding 
role), there may be limitations on its capability to perform a task that depend on the task 
instance. For example, several people in a company may have an "approver" role for 
purchase orders, but depending on the type and value of products ordered, not every one may 
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qualify to approve every order. The concept of scope is introduced to model such instance- 
dependent restrictions of resource capabilities. 

RESOURCES 

[0067] Resources can be human or automated (machine or system resource). In addition, an 
external resource type is introduced to model resources that may be beyond control of; 
unknown to, or irrelevant for, the process owner (opaque resource). It is understood that 
while the three types of resources (human, system, external) appear identical at this level of 
the model, differences become apparent in extensions and refinements, such as for process 
simulation or IT implementation. For example, human resources may eventually be mapped 
to entries in a corporate directory. System resources will be implemented by applications, 
machines, or automated tools, and may require connectors or adapters to participate in 
automated process execution. External resources will be different fijom the other two types in 
throughput simulations (the quantity and availability of the resource may be unknown, or 
unlimited), cost calculations (their cost is incurred by a third party), and IT implementations 
(their interactions require a B2B gateway). 

[0068] Resources are characterized by cost and availability, and should be thought of as 
"tangible** process actors having a distmguished identity (for example: Accountant Bill Smith, 
SAP System 4224, Airline reservation service www.flvrightcomV Resources are not to be 
confounded widi roles, which designate mere ce^abilities (for example: manufacturing 
specialist, travel agent, lead buyer, expense account approver). The same role can be taken on 
by resources with very different cost characteristics: for example, depending on who approves 
an expense account, the cost per hour in performing this task may vary greatly. As will be 
discussed in greater detail hereinbelow. 

[0069] As an example, a human resource may be an employee in the accounting department, 
or a team of four IT specialists. An example for a system resource is an SAP R/3 system. An 
example for an external resource is an airline reservation service. 



<?xmiveision==="1.0"eiicodmg='OTF-87> r • 
<resourceModel > ! 
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<iumanResourcename="AccoimtingOerk01"^ 



[0070] Resources may be aggregated. Aggregations of human resources, system resources, or 
external resources define a new (compound) resource of the same type. Aggregations of 
resources having different types creates a new "un-typed" resource. Combining un-typed 
resources with any resource will again create an im-typed resource. For example: 
Aggregations of human resources may be thought of as "teams" or "woik groups". Defining 
aggregations of system resources, as well as "mixed bags" of human and system resources, 
may be useful when these are usually deployed in combinatioiL For example, an accounting 
process may require a resource consisting of a member of the accounting department and the 
corporate accounting system; a rescue operation may require a helicopter, a pilot, and a 
physician. 

[0071 J Furthermore, resource aggregations may be nested, and three basic aggregation types 
are allowed: a bag (unordered set); a sequence (ordered set); and a choice (alternatives). If no 
aggregation type is specified, a bag is the default When assigning compound resources, the 
assignment of a bag will bind all resources it contains to the task. The assignment of a choice 
indicates that one of the resources in this set wiU be assigned; its selection is subject to 
availability, scope, or other runtime constraints, but no ranking or preference for picking a 
particular resource is indicated in the resource model. The semantics of assigning a sequence 
are similar to assigning a choice (one resource will be picked), but the sequence pre-defines 
some preference or priority in making this selection. An sample for a resource bag is a work 
group; an example for a sequence is a list of shipment services ranked by cost or speed; an 
example for a choice is a set of corporate chauffeurs. 



<rcsoiirceModei3^ t^' 
<tesources> 



<humabResoiji^^ name=="The Hauling Squad" aggrcgatioTiJ>^e=;'bag"> 

S'^, . <huma]bRcsoWe , - :c \ 

" <hunmiigS6urcl^e=£dm^ ' ^ ' 




<iyotf6e nTO^**the bvemigfet Expr^s^fe^": ? 
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, . .<resource tiame^nrhc courier Service"/> ^ 
' \ <resourccjiame=^ePostd Servicc"/> J/ . 
<resource> . . ff. 

. ,<hUinanRcsourcenamF="Lin» 
'j '^;, / ; , ; <liumanReMurce h^ 

" /y- <huj^anResourcc name=t^B. Bakcr''/> ^ 

' ' </hunianResourc^ ^ , , « * - 



[0072] Finally, resources may be owned by organizations, which may be internal (e.g., 
departments, divisions) or external to the enterprise (e.g., business partners, external service 
providers). Modeling these organizations, their hierarchical structures, and their ownership of 
resources, however, is outside the reahn of the core model. Such capabilities may be added in 
a model extension, for example, for process simulation. 



ROLE 



[0073] The functional capabilities of resources are described by assigning them roles, which 
are defined as aggregations of capabilities to perform business tasks. In IT implementations 
of business processes, roles are frequently used to denote authorizations or permissions to 
perform business functions. In an enterprise security model based on BOpS, the role concept 
introduced herein may be extended in this way. The assignment of a role to a resource may 
be scoped, in which case the resource's capability to perform the role is not universally 
granted for all task instances, but depends on the task at hand. As an example, a car 
manufacturer defines a corporate lead buyer role for procurement agents. A lead buyer's job 
is to ensure that purchasing contracts for production material are in line widi the corpomte 
procurement strategy. In a corpomte procurement process this role may aggregate the 
capabilities to "approve blanket orders", "change supplier ratings", and "set supplier volume 
limits". However, whether an employee having the lead buyer role may actually perform 
tiiese tasks depends on the class of material purchased (its so-called commodity type) as well 
as the geographic location of the supplier. Thus, the lead buyer role is "scoped" by supplier 
location and cormnodity type. Examples for such scoped lead buyer roles would be: "lead 
buyer for tires purchased fcom U.S. based suppliers", "lead buyer for any class of material 
purchased fix)m German suppliers", or "worldwide lead buyer for shock absorbers". 
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<resourceModel> . 7 '~ ~ :\ ■ ■ -'^ ^ 

<!~ Declaring the Jead^uyer rol^ --> ' ' ' 

<n>lename="leadbuyer"/> 



<!-- Declaring atead Buyer, and down-scgpiri^eciead buyer #e 



■ ■ '^fcsouxcenamer^f Patricia Goli^^ 



<ix>les> 



v^./^;.' . ^ v-^scopcna^ ' 

k''^. : . * vL- .<icope nam^rsuR>Iia- location" valiife=2United States"/^' 



<?resourcei> 



[0074] Scopes are modeled in BOpS as name-value pairs assigned to a resource's roles. They 
"down-scope" the role for the resource. The scope name defines a domain for (be scope 
(examples are: commodity type, supplier location, sales region, customer status) and the 
scope value the restriction of the scope within that domain (for example: commodity type = 
64, siqyplier location = Germany, sales region = EMEA, customer status = Gold, . . .). Down- 
scoping the roles assigned to resources -referred to as resource gualifications-impUci&y 
requires that a "scoping algorifhm" be defined for each task requiring such a scope restricted 
role: it must map each instance of the task into the various scope domains defined for the 
roles it requires. 

[0075J la the above example, the car manufacturer's procurement process includes a contract 
approval task to be performed by a lead buyer. This task has an associated scoping algorithm, 
which determines the appUcable commodity type and supplier location for each contract. 
This will involve parsing die contract and looking up the commodity type for each line item 
of production material ordered. It may also involve looking vp a suppUer's geogr^hic 
location in a supplier database. 

[00761 If several scopes are assigned fiom the same domain, then the resulting scope is their 
union. After forming the union of scopes by domain, the total scope is defined as the 
Cartesian product across domains. Thus, for example, a sales agent whose scope is defined as 
(sales region = Germany, sales region =^tts<rKi, sales region = Switzerland) is responsible for 
the three German-speaking countries (union of die tiiree scopes). A lead buyer whose scope 
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is defined as (commodity type = light bulbs, commodity type = wiper blades, supplier 
location = Texas, supplier location = Arizona, supplier location = New Mexico) is responsible 
for purchases of light bulbs and wiper blades fiom suppliers located in these three states 
(Cartesian product of xmions). 



<resourceModel>/ ^ ' " ^. . ' . ' / ^ - ' ^ 

' .^,,5^5- ^<role naine=*'sales^agenf!/> . "V v - 



- . ' * - ' AC r <ix)le iiam^"sales ag«it*^ \r . ^ 

' <scopc name="sdes i^on" valu 

'.sT'^^ ^' . ' ;'<scope|iam^*'sales,regioV 

i:Eiiiiif!ffiililiiii|^^ 



i<s5co^e name^'supplie 
.k^'Vi:<^peiiameT^si^ 
^ . .^Vr t<scope iimiieF="suppiier location" valu€^"NewMexic6"/> 



[0077] Frequently, scopes have a hierarchical structure. Examples include geographic 
locations (states within countries within geographic regions), corporate units (departments 
within divisions within corporate groups), or categories of products. Defining a scope as a 
node in such a structure is equivalent to defining it as the set of all subordinate leaves. Thus, 
for example, an electronics manufiicturer defines a sales director role whereby a sales director 
is responsible for a geographic area. The company's sales areas are hierarchically structured, 
with geographies (NorthAmerica, LatinAmerica, EMEA, AsiaPacific) at the top level, 
individual countries at the next level, and states or provinces within countries at the lowest 
level. 



[0078] In order to document the hierarchical structure of a scope domain, or to enumerate all 
possible scope values, one may declare the set of permitted scope values as part of the role 
definition. If such a "scopes" declaration is present, it is understood that the scope restrictions 
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for resource qualifications must be a subset of the scopes thus declared. As an example, an 
airline company defines a customer service representative role which is scoped by customer 
status. The role definition for customer service representative lists Silver ^ Gold, and Platinum 
as the three possible scope values for customer status. Declaring a cxistomer service 
lepresentative with customer status == None or customer status = All would thus be an error. 
If no scope values had been declared under the customer service representative role, then any 
value for customer status would have been permissible. Also shown in the following XML 
example is the sales director role introduced above, scoped by geographic area. The role 
declaration includes the hierarchical structure of the company's sales regions. 

CONSTRAINT MODEL 

[0079] The constraint model describes the constraints that must be satisfied for a BOpS 
model to be semantically vaUd. It reflects the operational semantics of the model. 
Constraints may be of 2 types: 1) Metadata Constraints - which are semantic constraints that 
need to be specified over and above the schema constraints. These are schema level 
constraints (but were unable to be specified by the schema) and will usually pertain to all 
lostance documents; and 2) Model Constraints - which are semantic constraints specific to an 
histance document These constraints reflect the business rules/logic that need to be 
evaluated in order to validate the model. 

[0080] While the invention has been particularly shown and described with respect to 
illustrative and preformed embodiments thereof, it will be understood by those skilled in the 
art that the foregoing and other changes in form and details may be made therein without 
departing fi-om the spirit and scope of the invention which should be limited only by the scope 
of the appended claims. 
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